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ART-UNIT: 271 

PRIMARY-EXAMINER: Tkacs; Stephen R. 
ATTY-AGENT-FIRM: Stanger; Leo 

ABSTRACT : 

An improved system for consumer payors to save and donate whenever they use cash at 
a point of sale terminal, write a check, use an ATM machine, or use a credit or 
debit card. The POS system is a network composed of subscriber/payors, neutral 
merchant/collectors, a central clearinghouse, and provider accounts. The Rounder 
system is a network composed of subscriber/payors, payees, account managers, and 
provider services. The systems together provide subscriber/payors with a seamless 
way to save/donate every time they spend. 

34 Claims, 28 Drawing figures 
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L17: Entry 29 of 33 



File: USPT 



Aug 29, 2000 



DOCUMENT-IDENTIFIER: US 6112191 A 

TITLE: Method and system to create and distribute excess funds from consumer 
spending transactions 

Brief Summary Text (2) : 

The present application relates to improved methods and systems to create excess 
funds from traditional consumer spending transactions using cash, checks, credit or 
debit card. The excess funds created are then put aside in special accounts for 
future spending. 

Drawing Description Text (5) : 

FIG. IF is a block diagram of the Data and Funds Transfer used in both PCS systems 
embodying features of the invention. 

Detailed Description Text (3) : 

(1.) In FIG. lA, an "open" PCS network embodies a four level spending/saving system 
comprised of Level 1 SP (multiple subscriber/payors) , who tender excess payments or 
deposit excess funds to Level 2 MC (multiple merchant /collectors ) , who in turn make 
computer entry of data and finds for electronic transfer to Level 3 CCC (a singular 
managed clearinghouse central computer) , who in turn transfers data and funds to 
Level 4 (multiple provider accounts) , for the final purchase of products or 
services . 

Detailed Description Text (5) : 

After the amount of excess funds is determined by the MC s electronic cash register 
(ECR) , the SP makes a deposit into a clearinghouse central computer (CCC) by 
providing a transaction card or an account number to the MC. The MC then swipes the 
card or enters the account number through an ECR or a draft capture remote terminal 
to record the time, the terminal location, the amount of funds entered, and the 
account number used. The terminal or cash register then prints out a receipt of the 
depositing transaction and the MC returns the card and the receipt to the SP. 

Detailed Description Text (7 ) : 

Each terminal location follows the same reporting procedure so that the CCC will 
have a record of all transactions made into the system, regardless of the location 
of the terminals. The files transferred to the CCC contain details of each 
deposited transaction by the identification of the account, the amount of the 
deposit, the date, and the terminal that accepted the deposit . The actual transfer 
of cash into the system starts when the MC deposit the cash received from the SP 
into their bank for EFT transfer to the clearinghouse's bank account and concludes 
with the CCC EFT transferring funds to each listed PC (provider account) per the 
transaction records received from the merchant terminals. The transfer of cash from 
one account to the next is accomplished by the usual and customary bank EFT 
transferring through the ACH (Automatic Clearing House) or via EDI (Electronic Data 
Interchange) . 

Detailed Description Text (8) : 

Effectively, the system allows each SP the ability to make multiple deposits, in 
varied cross country locations, into terminals operated by unrelated parties, 
depositing as little as a penny in any one transaction, and often on a 24 hour 
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demand basis . 

Detailed Description Text (9) : 

The MC that operate the ECR terminals are at the time of depositing both neutral 
and passive as to the selection of the consumer's provider (s), as well as not 
directing the distribution of funds to the consumer's provider(s). Only in this 
system are SP able to deposit their excess change created when dealing with 
multiple and diverse payees. The money is deposited into an "open" network that 
will pool and then transfer the once fragmented funds onto PA selected by the SP. 
In this system as compared to the existing state of art, the PA who will receive 
the deposited funds from the network need not also be the original collector of the 
deposits . Therefore, we have a "open" system that allows for a mix and match of 
diverse collectors and providers. 

Detailed Description Text (10): 

Under the system it is possible for one entity to provide both a collector and 
provider role, but under different and autonomous points in the network cycle. For 
example. Sears may enroll a subscriber consumer in a Sears store account allowing 
the consiamer to use their Sears issued mag stripe card to identify them when they 
deposit excess change into any merchant /collector terminal. In this capacity Sears 
is playing the role of a distinct provider in the network. The card may then be 
used to deposit excess funds at fast food restaurants, convenience stores, other 
department stores, etc. Also the SP could go into any Sears store and deposit 
excess funds into a Sears terminal for transfer to the network. On these occasions 
Sears would be playing a distinct role as a participating MC, within the network, 
and follow the same procedures as any other MC, as well as also being a PA at the 
end of the network chain. 

Detailed Description Text (11) : 

In FIGS. IB&C, the Clearinghouse Managed System (CMS) starts with Level 1, the 
subscriber /payors, tendering an excess financial payment to Level 2, 
merchant/collectors. They in turn enter the amount of the excess payment into an 
electronic cash register/remote terminals which then sends the funds and data on- 
line per transaction, or along with other deposits in a batched format, by a 
communication system to Level 3, clearinghouse central computer. Level 3 assigns 
the funds to an account previously opened by Level 1 SP through services provided 
by Level 3. The funds are then forwarded, when they reach pre-selected thresholds, 
by EDI (Electronic Data Interface) transfer to Level 4, the provider accounts, 
selected by Level 1 SP. 

Detailed Description Text (12) : 

The Clearinghouse Managed System (CMS) , has the network providing a more active 
role by the system's central computer enrolling the SP in accounts and then 
assuming the role of an account manager. Under this arrangement the network will 
direct the overall operation of the system, issue transaction cards (bar code, mag 
stripe and/or "smart" cards or devices), operate the system's central computer, 
provide both on-line and off-line communications between the PCS terminals and the 
central computer, accept funds, assume fiscal responsibility for the SP funds on 
deposit, maintain all account records, provide all outside payments to parties 
selected by the SP, and even allow the SP the ability to access their accounts for 
the purpose of receiving credit at the time of PCS purchase to pay the MC. Under 
the CMS, in addition to the network serving as an account manager, it will also 
appoint banks, credit card institutions, and merchant /collectors to assume 
additional fiduciary responsibilities. 

Detailed Description Text (13) : 

In FIGS. ID&E, the Provider Managed System (PMS) starts with Level 1, the 
subscriber/payors, tendering an excess financial payment to Level 2, 
merchant/collectors. They in turn enter the amount of the excess payment into an 
electronic cash register/remote terminals which then preferably send the funds and 
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data, along with other deposits in a batched format, by a communication system to 
Level 3, clearinghouse central computer. Level 3 then segregates the transactions 
per provider accounts. The data and funds are then forwarded, when they reach pre- 
selected thresholds, by EDI (Electronic Data Interface) transfer to the Level 4 
providers for account management and final distribution. Level 1 SP initially join 
the network by enrolling in accounts with Level 4 providers. 

Detailed Description Text (14): 

The Provider Managed System (PMS), is an "open" system that creates a network 
whereupon SP will directly enroll in accounts managed by PA, receive mag stripe, 
cards issued by the PA, and deposit their excess change at PCS locations to be 
transferred by the MC to a neutral network clearinghouse (CCC) . Under the PMS, the 
CCC will accept and process the transaction data and funds and forward both to the 
PA according to the card identification. The PA will then manage the accounts per 
the SP instructions. 

Detailed Description Text (15) : 

In the PMS scenario both the merchant/clearinghouse are passive as to the opening 
of accounts and the SP selections of the final distribution of the funds. Here both 
the payees and the clearinghouse only accept deposits and transfer both the cash 
and transaction records onto the end PA. 

Detailed Description Text (17) : 

In FIG. IF, in both the Clearinghouse Managed System or Provider Managed System the 
data transfer is sent via a proprietary network from Level 2 MC to Level 3. After 
processing by Level 3 selected data is sent via a proprietary network to Level 4 . 
On the funds transfer side Level 1 deposits the funds at Level 2 outlets. Level 2 
deposits the finds into the MC*s bank account and by EDI the finds are transferred 
to Level 3's bank account for final EDI to Level 4*s bank account. 

Detailed Description Text (21) : 

In the PMS embodiment of the invention the CCC acts as a clearinghouse and 
transfers all data and funds onto the respective PA for account management and 
final distribution. 

Detailed Description Text (22) : 

The CCC communications system CS also connects the CCC to charity computers CHy and 
other computer OCz, where y=l . . . k, and z=l . . . j such as bank computers, 
merchandise computers, debit account holders, credit card issuers, etc. These 
charities and other institutions are the ultimate receivers of the donations and 
deposits collected at the electronic cash registers ECRx. The CCC also includes a 
default account DA with consumer ledgers to hold moneys not otherwise allocated. 

Detailed Description Text (23) : 

The ECRx includes a change display for exhibiting cash transactions, credit cards, 
or check purchases. The display automatically operates to show numbers in question. 
A card reader CDx with a keypad KPx allows the SP or clerk to enter the deposit 
directly. The keypad KPx permits the SP to change the allocation for this 
transaction alone or permanently. The keypad KPx also allows the SP to reduce the 
amount deposited so that he can receive cash change. The terminal RTx or ECRx 
reports the deposit directly to the CCC via the communication system CS . The CCC 
prints out periodic reports for interested parties on a need-to-know basis. 

Detailed Description Text (26) : 

If the consumer gives the clerk the exact price nothing more need happen. However, 
if the money offered the clerk exceeds the price, the consumer may, if he or she 
wishes, choose to receive the change or to donate or deposit all or a portion of 
the change. To do the latter, he or she enters a card number into the keypad KPx or 
enters the card itself into the card reader CDx. The latter reads the number from a 
bar code or magnetic stripe on the card. The consumer can also enter into the 
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keypad how much of the total change, he or she is to receive, should be credited to 
various predetermined accounts in the CCC. The register ECRx reads the numbers 
entered into the keyboard or the number entered by way of the card reader CDx. 

Detailed Description Text (27) : 

In addition if SP wish to make a direct deposit of finds into the network, (rather 
than make a purchase and tender excess funds), all that is necessary is to enter 
the amount deposited into the ECRx and the funds will be transferred to the CCC. 

Detailed Description Text (29) : 

After receiving the data, the ECR accesses the CCC. The latter allocates the 
change, a portion of the change, or the amount of a direct deposit provided by the 
SP among various charity accounts CA and other accounts OA in the CCC. The 
distributions to various accounts are preprogrammed commands which the consumer has 
previously instructed the CCC to complete. For each deposit or donation made, the 
SP receives a printed receipt of the transaction from the ECRx or RTx. 

Detailed Description Text (30) : 

If desired, the consumer can choose to deposit only a fraction of the difference 
between the cash presented and the price. The consumer then enters the amount to be 
deposited and receives the appropriate cash change. 

Detailed Description Text (31) : 

According to an embodiment of the invention, with every transaction, the computer 
electronically transfers all amounts allocated to each charity CHy immediately, as 
soon as the computer can access the charity computer, or when there is a sufficient 
amount of money. In this way the donor is always assured that the contribution 
takes effect. Deposits in the other accounts OA may be sent immediately or held 
until a sufficient amount is accumulated to be acceptable by the other 
institutions . 

Detailed Description Text (34): 

In step 110, the clerk then enters the amount of the cash payment into the ECRx. 
Under normal circumstances, the cash payment will equal or exceed the total 
spending price unless there is deposit of cash into the system without a purchase. 
However, the invention allows the SP to withdraw moneys from a credit balance in 
one of the accounts recorded in the CCC. While unlikely, this may also occur with a 
credit or debit card sale. Thus, in some situations, the amount of cash may fill 
short of the total price. In step 114 the cash register determines if the amount of 
cash exceeds the total price. 

Detailed Description Text (40) : 

If the answer to step 140, namely to the question whether there is more cash than 
the price, is yes, step 154 causes the ECR to display a message asking whether the 
customer wishes to retain some of the change due. If yes, the ECR prompts the 
customer to enter into the keypad KPx how much he or she wishes to retain or 
deposit . In step 157, the cash register ECR indicates to the clerk to give the 
appropriate net change and shows the net deposit amount. 

Detailed Description Text (56) : 

In step 306, the clerk enters the amount of payment, on most occasions cash, into 
the terminal computer. However, if a check, debit or credit card is tendered by the 
SP, any excess payment effectively becomes cash and is therefore eligible for 
deposit . 

Detailed Description Text (64): 

Referring now to FIG. 5B if the answer is yes, in step 332 the subscriber or the 
clerk enters the subscriber's card into the terminal. The terminal computer reads 
the card and automatically records all of the cents in the PCS change as a deposit 
or contribution. If the subscriber wishes to add in all of the change (coins and 
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bills) 332A is entered into the computer. If the subscriber wishes to add in a 
specified portion of the change, 332B is prompted into the keypad along with the 
specified amount, for example $1.54 out of $2.54 in available change. 

Detailed Description Text (80) : 

In FIG. 7 Level 1 a subscriber subscriber (SP) makes an exact payment using a 
check, credit or debit card and tenders the draft to a payee on Level 2 who in turn 
deposits the draft for customary authorization, approval, and payment by Level 3 
Account Managers (AM) (as in banks or credit institutions) . Under the provisions of 
the invention Level 3 AM will now also add or subtract a predetermined calculation 
to the face amount of the draft or the account entry itself for the purpose of 
creating an excess payment. The amount of excess payment called a rounder amount is 
then added to the face amount of the draft and the total number is then debited (as 
in withdrawals or account fees) or added (as in deposits or interest payments) to 
the account balance. Level 3 AM will then manage the funds and make distributions 
to Provider Services (PS) Level 4 (as in mutual funds, annuities, etc.). 

Detailed Description Text (82) : 

The rounder system versus the PCS system occurs in a different environment and at a 
different point in the commercial purchasing cycle. The processing of transactions 
occurs at the "back end" of the commercial cycle when check and credit drafts are 
debited against their existing account balances. Effectively, the invention adds 
(as in withdrawals or account fees) or subtracts (as in deposits /payments or 
interest dividends) an amount of excess funds, e.g. $1, $2.14, $5.01, $10, $0.28, 
etc., to the face amount or number of entries and then adjusts the account balance 
accordingly. The amount of excess funds are then displayed in the account and 
periodically transferred to accounts for provider services, i.e., mutual funds, 
annuities, merchandise, charities, etc. 

Detailed Description Text (119) ; 

In step 775 the computer transfers out the charity contributions, savings, 
investments, and other accounts. 

Detailed Description Text (128) : 

The detailed computer processing required to create rounder account contributions 
is continued in FIG. 9C in regard to deposits or fee income. 

Detailed Description Text (129) : 

In the processing of deposits or interest into accounts we reverse the process and 
decrement the amount of money going into the checking account so that we can create 
excess funds. Therefore, we can apply similar rules, as previously discussed, when 
the invention dealt with account withdrawals, but only in a decrementing fashion. 

Detailed Description Text (130) : 

In the preferred embodiment we will decrement deposits and interest payments only 
to eliminate coin amounts. 

Detailed Description Text (131) : 

Starting at the top, in step 634 the computer asks, Is this transaction a deposit 
or interest fee? 

Detailed Description Text (134): 

If the answer is no, in step 64 0 the rounder account contribution equals zero since 
there are no coins in the entry amount of the deposit . The program then goes to 
step 644. 

Detailed Description Text (135) : 

If the answer is yes, in step 642 the cents are subtracted from the face amount and 
the coins become rounder contributions. For example, if the deposit was for $10.14 
the rounder would take off the $0.14 and the net deposit would be for $10.00. 
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Detailed Description Text (136) : 

In step 64 4 the rounder amount is subtracted from the face amount to determine the 
total deposit . 

Detailed Description Text (137) : 

In step 64 6 the total deposit is then added to the existing balance to determine 
the new balance. 

Detailed Description Text (138): 

The ability for the invention to remove coins from checking account deposits will 
allow for easier balancing of checking accounts. 

Detailed Description Text (152) : 

If the answer is no, computer goes to step 743 and asks, Is this transaction a 
deposit or interest? 

Detailed Description Text (168) : 

In step 990 the computer transfers out the charity contributions, savings, 
investments, and other accounts. 

Detailed Description Text (182) : 

If the answer is no, in step 840 the rounder account contribution equals zero since 
there are not any coins in the entry amount of the deposit . The computer then goes 
to step 844. 

Detailed Description Text (183): 

If the answer is yes, in step 842 the cents are subtracted from the entry amount 
and the coins become rounder contributions. For example if the payment was for 
$500.14, the rounder would take off the $0.14 and the net deposit would be for 
$500.00. 

Detailed Description Text (202) : 

The invention also provides a four level rounder system (RS) for 

subscriber/subscribers to create excess funds from account entries connected with 
transactions paid for by check, ATM machine, credit, or debit card (which can occur 
at a variety of commercial points: PCS counters, on a person to person basis, by 
mail, by wire transfer, by telephone, by computer, etc.). The rounder system would 
apply a computerized rounder amount to create excess funds in which the active 
cooperation of the payee is not needed and when the face amount of the payment 
being tendered is not in excess of the actual purchase price as the required means 
to establish the excess funds. 
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ART-UNIT: 275 

PRIMARY-EXAMINER: Stamber; Eric W. 
ASSISTANT-EXAMINER: Kanof; Pedro 

ATT Y-AGENT- FIRM: Sterne, Kessler, Goldstein & Fox P.L.L.C. 
ABSTRACT : 

An online centralized financial products exchange system. The invention is a 
system, method and computer program product that creates a "marketplace" for end- 
to-end financial products life cycle transactions. More particularly, the invention 
provides a centralized exchange system for the trading of loans. The system 
includes a plurality of Web servers for receiving and providing loan information 
from and to subscribers on several Web clients and a database server for searching 
the pre-set rules to match potential buyers with sellers. The system also includes 
a database for storing information relating to negotiations (i.e., bidding) for the 
sale of loans and for storing pre-set rules for pre-registered buyers and sellers. 
The system further includes a database and server for storing risk/return 
information that is made available to subscribers for analysis. 

36 Claims, 26 Drawing figures 
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File: USPT 



May 15, 2001 



DOCUMENT-IDENTIFIER: US 6233566 Bl 

TITLE: System, method and computer program product for online financial products 
trading 

Brief Summary Text ( 6) : 

Financial products are one of the types of products available through electronic 
commerce activities. Consumer loan products, one example of financial products 
available through electronic commerce, are typically divided into two categories — 
conforming (or conventional) loans and non-conforming (or non-conventional) loans. 
Conforming loans are low risk loans and include traditional primary residence 
mortgage loans to consumers with good credit histories and loans to consumers who 
qualify under certain government-backed loan programs (e.g., Federal Housing 
Administration (FHA) or the Veterans Administration (VA) ) . 

Brief Summary Text (21) : 

The mortgage banker pools the loans and advertises to investors who may be 
interested in purchasing a pool of loans. For example, a typical pool may consist 
of 300 loans with an estimated total value of $30 million or may consist of 3000 
loans with an estimated total value of $300 million. The potential investor, 
typically a bank, securitization company or another mortgage banker, will review 
the information for each loan in the pool and either accept, decline, or reserve 
its decision for each loan in the pool. Then, the investor may send a revised pool 
back to the mortgage banker with an offering price to buy the revised pool. The 
mortgage banker then may add other loans to the pool and resend the pool to the 
investor for review. This negotiation (or bidding) continues until a sale is made 
or rejected. The rejected loans may be used already in other pools or may be used 
directly for securitization, as discussed below. 

Brief Summary Text (23) : 

Naturally, investors of the loan pools have developed certain rules for evaluating 
the suitability of the loans for securitization. However, the mortgage bankers' 
rules used for grouping certain loans together in a pool may be different from the 
rules used by the investor in deciding which loans it would like to purchase in a 
pool and the rules used buy lenders in making the underlying loans in the first 
place. For example, the mortgage banker in an attempt to sell the low risk and high 
risk loans together, may want to group together loans made to borrowers with high 
FICO scores with loans made to borrowers with lower FICO scores. However, the 
investor may have rules which do not allow the purchase of any pool with a loan 
made to a borrower having a FICO score less than a predetermined amount. As a 
result, negotiations between the mortgage banker and the investor must occur in 
order to decide on a pool and a price that is suitable to both parties. It is 
important to note that although the rules are devised as guidelines for buying and 
selling loans, these rules may be disregarded or altered on a case-by-case basis. 
Further, each entity described above may frequently change its rules based on 
market conditions and other relevant factors. 

Detailed Description Text (21) : 

The present invention relates to a system, method, and computer program product for 
analyzing, valuating, buying and selling financial products, such as loans. The 
loans contemplated for use with the present invention include, for example. 
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conforming and non-conforming loans, such as residential mortgage loans, multi- 
family mortgage loans, commercial mortgage loans, consumer and commercial 
installment loans, small business loans, student loans and vehicle/boat/plane 
loans. Although the embodiment described herein relates specifically to loans, it 
would be apparent to one skilled in the relevant art(s) that the present invention 
could also be used for analyzing, valuating, buying and selling a variety of other 
financial products, including, for example: (1) revolving lines of credit, such as 
credit card accounts and home equity lines of credit, (2) annuities, (3) insurance 
products, and (4) consumer and commercial assets, such as certificates of deposit . 

Detailed Description Text (103): 

As shown in FIG. 7, a loan agent, Tom Smith, has a personal account on system 200, 
in which his current loan application data is stored. A GUI 702, shown in FIG. 7, 
includes a window 704 to display the primary applicant's name, the loan request 
amount and the status of the loan application. GUI 702 also provides the loan agent 
with a loan summary window 706 to display detailed information for each pending 
loan application. Each time a new loan application is initiated, the application is 
added to the loan agent's account . 

Detailed Description Text (111) : 

Referring to FIG. 14, a GUI 1404 shows an interface that can be used by the loan 
agent to search the marketing database for preliminary applicant information. When 
a loan agent receives a call from an applicant, the marketing database can be 
searched, using, for example, the applicant's last name and zip code, as shown in 
windows 1408 and 1412, or using a priority code, as shown in a window 1416, to 
match the applicant with the pre-existing information in the marketing database. 
The search results are displayed in a window 1420. As shown in FIG. 14, depending 
on the detail of the search information, more than one match may appear in window 
1420. The particular applicant's name is then highlighted, and the applicant 
information for that applicant is displayed to the right of window 1420. When the 
user depresses a button 1424, labeled " Qualify ", the selected applicant's 
information is automatically entered into GUI 704 so that the loan agent must only 
verify this information and does not need to manually re-enter this information, 
thereby saving time. 

Detailed Description Text (117) : 

In a step 636, the manager of the loan origination company then determines, using 
workstation 24 6, whether to give final approval to the applicant's loan request. If 
final approval is denied, the loan application data is archived in origination 
archive 226 of the loan application data warehouse, in step 620 and the flow 
follows as described above. If the loan is given final approval, the loan 
originator and application proceed through loan closing in a step 640 and funding 
is provided to the loan applicant in a step 644. Similar GUIs (not shown) are 
available through system 200 for use in loan closing step 636. 

Detailed Description Text (120) : 

A person wishing to sell a loan or loan pool may access system 200 via workstation 
280d to publish a loan or loan pool for sale. In the case of a loan pool, the 
seller may first access system 200 via workstation 280f to create the loan pool. 
Workstation 280f can be used to search currently available loans for a seller using 
certain predetermined criteria (e.g., FICO score, loan amount, loan term, etc.) to 
generate a pool of loans satisfying the search criteria. This pool can then be 
saved and stored in databases 221 and 222 of portfolio subsystem 220. 

Detailed Description Text (122) : 

In one embodiment, subscribers each have a profile archived in system 200. The 
profile includes the subscriber's contact information, such as, the name of the 
company for which the subscriber works, the subscriber's telephone number (s), fax 
number (s), address information and electronic mail address information. The profile 
also includes a list of all loans or loan pools that have been published by the 
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subscriber for sale in system 200. Other subscribers can access this profile 
information for review. The subscriber can also access his own profile to update 
the information therein, in one embodiment, the subscriber can set up his rules for 
his profile using the loan criteria to indicate the conditions under which the 
subscriber wishes to be notified by the system of a published loan or loan pool. 
The subscriber may be provided with the option of whether to maintain his pre-set 
rules as private, or whether to allow other subscribers to access them. 

Detailed Description Text (124): 

In one embodiment, when the subscriber logs onto system 200, he receives a "buy 
alert" that displays new loans or loan pools that have entered the system 200 and 
that meet the subscriber's pre-set rules. Also, while the subscriber is logged into 
his account on system 200, a "buy alert" may flash on the subscriber's computer 
screen if a new loan or loan pool meeting his pre-set rules enters the system. 

Detailed Description Text (130) : 

The seller who published the loan(s) is then notified by exchange system 200 that 
an offer has been made, as shown in a step 1524. Notification can be effected to 
the seller in any of the same manners as discussed above with respect to step 1512. 
Alternatively, the seller may have a personal account in exchange system 200 that 
he periodically checks. Exchange system 200 may notify the seller of incoming 
offers simply by posting the offer to the seller's account . 

Issued US Original Classification (1) : 
705/37 

Current US Original Classification (1) : 
705/37 

Field of Search Class/SubClass (2) : 
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ART-UNIT: 215 

PRIMARY-EXAMINER: Millin; Vincent 
ASSISTANT-EXAMINER: Thompson, Jr.; Forest 0 



In one embodiment, an architecture that consummates an electronic transaction 
between a first electronic device, such as an acquirer device, a second electronic 
device, such as an issuer device, and a plurality of electronic terminals, such as 
merchant terminals, by establishing a communication between the plurality of 
devices and terminals and accumulating transactions that are approved by the second 
electronic device. Then, periodically the plurality of transactions are settled 
using a transfer of monetary value between the first electronic device and the 
second electronic device. For example, the present invention uses electronic cash 
transfer to replace conventional settlement, which requires the use of a third- 
party settlement service. 

24 Claims, 130 Drawing figures 



ABSTRACT : 



Previous Doc 



Next Doc 



Go to Doc# 



h e b 



bgeeef c e 



e ge 



Record Display Form 



Page 1 of 21 



First Hit Fwd Refs 



Previous Doc Next Doc 



Go to Doc# 




Lll: Entry 9 of 19 



File: USPT 



Nov 27, 2001 



DOCUMENT-IDENTIFIER: US 6324525 Bl 

TITLE: Settlement of aggregated electronic transactions over a network 
Brief Summary Text (2) : 

A portion of the disclosure of this patent document contains material that is 
subject to copyright protection. The copyright owner has no objection to the 
facsimile reproduction by anyone of the patent disclosure, as it appears in the 
Patent and Trademark Office patent files or records, but otherwise reserves all 
copyright rights whatsoever. 

Brief Summary Text (6) : 

The present invention relates to an electronic representation of a monetary system 
for implementing electronic money payments as an alternative medium of economic 
exchange to cash, checks, credit and debit cards, and electronic funds transfer. 
The .Electronic-Monetary System is a hybrid of currency, check, card payment 
systems, and electronic funds transfer systems possessing many of the benefits of 
these systems with few of their limitations. The system utilizes electronic 
representations of money that are designed to be universally accepted and exchanged 
as economic value by subscribers of the monetary system. 

Brief Summary Text (7) : 

Today, approximately 350 billion coin and currency transactions occur between 
individuals and institutions every year. The extensive use of coin and currency 
transactions has limited the automation of individual transactions such as 
purchases, bank account deposits, and withdrawals. Individual cash transactions are 
burdened by the need to have the correct amount of cash or providing change. 
Furthermore, the handling and managing of paper cash and coins is inconvenient, 
costly, and time consuming for both individuals and financial institutions. 

Brief Summary Text (8) : 

Although checks may be written for any specific amount up to the amount available 
in the account, checks have very limited transferability and must be supplied from 
a physical inventory. Paper-based checking systems do not offer sufficient relief 
from the limitations of cash transactions, sharing many of the inconveniences of 
handling currency while adding the inherent delays and costs associated with 
processing checks. To this end, economic exchange has striven for greater 
convenience at a lower cost, while also seeking improved security. 

Brief Summary Text (9) : 

Automation has achieved some of these qualities for large transactions through 
computerized Electronic Funds Transfer ("EFT") systems. EFT is essentially a 
process of value exchange achieved through the banking system's centralized 
computer transactions. EFT services are a transfer of payments utilizing electronic 
"checks," which are used primarily by large commercial organizations. 

Brief Summary Text (10): 

Home banking bill payment services are examples of an EFT system used by 
individuals to make payments from a home computer. Currently, home banking 
initiatives have found few customers. Of the banks that have offered services for 
payments, account transfers, and information over the telephone lines using 
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personal computers, less than one percent of the bank's customers are using the 
service. Home banking has not been a successful product, because, for example, the 
customer cannot deposit and withdraw money as needed in this type of system. 

Brief Summary Text (11) : 

Current EFT systems, credit cards, or debit cards, which are used in conjunction 
with an on-line system to transfer money between accounts, such as between the 
account of a merchant and that of a customer, cannot satisfy the need for an 
automated transaction system providing an ergonomic interface. Examples of EFT 
systems that provide non-ergonomic interfaces are disclosed in U.S. Pat. Nos . 
5,476,259; 5,459,304; 5,452,352; 5,448,045; 5,478,993; 5,455,407; 5,453,601; 
5,465,291; and 5,485,510. 

Brief Summary Text (12) : 

To implement an automated, convenient transaction that can dispense some form of 
economic value, there has been a trend towards off-line payments. For example, 
numerous ideas have been proposed for some form of "electronic money" that can be 
used in cashless payment transactions as alternatives to the traditional currency 
and check types of payment systems. See U.S. Pat. No. 4,977,595, entitled "METHOD 
AND APPARATUS FOR IMPLEMENTING ELECTRONIC CASH," and U.S. Pat. No. 4,305,059, 
entitled "MODULAR FUNDS TRANSFER SYSTEM." The more well-known techniques include 
magnetic stripe cards purchased for a given amount and from which a prepaid value 
can be deducted for specific purposes. Upon exhaustion of the economic value, the 
cards are thrown away. Other examples include memory cards or so called smart cards 
which are capable of repetitively storing information representing value that is 
likewise deducted for specific purposes. A smart card is generally a hand-held 
portable device that includes a microprocessor, input-output ports, and a non- 
volatile memory (e.g., a few kilobytes of memory). 

Detailed Description Text (58) : 

Merchants generally require a mechanism for verifying legitimate cardholders of 
valid, branded bankcard account numbers. A preferred embodiment utilizes technology 
to link a cardholder to a specific bankcard account number and reduce the incidence 
of fraud and thereby the overall cost of payment processing. Payment processing 
includes a mechanism that allows for cardholder confirmation that a merchant has a 
relationship with a financial institution allowing it to accept bankcard payments. 
Cardholders should also be provided with a way to identify merchants with whom they 
can securely conduct electronic commerce. Merchant authentication is ensured by the 
use of digital signatures and merchant certificates. 

Detailed Description Text (62): 

A Single Account Wallet 160 at bank web site 182 represents the MIME message that 
is created by the Certificate Issuance system. This MIME message contains a 
VeriFone wallet. The VeriFone wallet contains a single payment instrument and the 
certificate associated with it. For security reasons, the private key is not 
included in the wallet. The consumer has to specify a private key before using the 
instrument for payment. When the consumer is issued the certificate, this MIME 
message is sent to a browser, which resides at a consumer desktop 186. The browser 
launches a Certificate Installation application 174, 144, which is defined as a 
helper application in the browser. The Certificate Installation application 174, 
144 reads the MIME message and installs a wallet into a wallet database 158. 

Detailed Description Text (66) : 

Certificate Issuance CGI scripts 162 and Single Account Wallet 160 at Bank Web Site 
182 is processed as described in the native system. The Certificate Installation 
Applet of Bank Web Site 182 is utilized by the Certificate Issuance CGI scripts 162 
system to deliver a consumer's certificate to the consumer's desktop. 

Detailed Description Text (83) : 

Payment authorization is a process by which permission is granted by a payment 
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gateway operating on behalf of a financial institution to authorize payment on 
behalf of the financial institution. In one embodiment, payment authorization is a 
process that assesses transaction risk, confirms that a given transaction does not 
raise the account holder's debt above the account ' s credit limit, and reserves the 
specified amount of credit; and payment capture is a process that triggers the 
movement of funds from the financial institution to the merchant's account after 
settlement of the account. 

Detailed Description Text (90) : 

FIG. 4 depicts the stages of generating and transmitting a payment authorization 
request in accordance with a preferred embodiment. FIGS. 5A through 5F depict views 
of the payment authorization request and its component parts in accordance with a 
preferred embodiment. In function block 410, merchant computer system 130 creates a 
basic authorization request 510. Basic authorization request 510 is a data area 
that includes information for determining whether a request should be granted or 
denied. Specifically, it includes such information as the party who is being 
charged, the amount to be charged, the account number of the account to be charged, 
and any additional data, such as passwords, needed to validate the charge. This 
information is either calculated based upon prior customer merchandise selection or 
provided by the customer over secure link 270 established in the customer-merchant 
general-purpose secure communication protocol session. FIG. 5A depicts basic 
authorization request 510 in accordance with a preferred embodiment. 

Detailed Description Text (123) : 

FIG. 10 depicts the stages of generating and transmitting a payment capture request 
in accordance with a preferred embodiment. FIGS. IIA through IIF depict views of 
the payment capture request and its component parts in accordance with a preferred 
embodiment. In function block 1010, merchant computer system 130 creates a basic 
capture request 1110. Basic capture request 1110 is a data area that includes 
information needed by payment gateway computer system 140 to trigger a transfer of 
funds to the merchant operating merchant computer system 130. Specifically, basic 
capture request 1110 includes a capture request amount, a capture token, a date, 
summary information of the purchased items, and a Merchant ID (MID) for the 
particular merchant. FIG. IIA depicts basic capture request 1110 in accordance with 
a preferred embodiment. 

Detailed Description Text (138) : 

In function block 1245, payment gateway computer system 140 determines the 
financial institution for which capture is requested by inspection of basic capture 
request 1110. Payment gateway computer system 140 contacts the appropriate 
financial institution using a secure means (e.g., a direct-dial modem-to-modem 
connection or a proprietary internal network that is not accessible to third 
parties), and using prior art means, instructs a computer at the financial 
institution to perform the requested funds transfer after settlement. 

Detailed Description Text (150) : 

In function block 1430, merchant computer system 130 verifies payment gateway 
computer system's 140 signature public key certificate 1320. Merchant computer 
system 130 performs this verification by making a call to the certification 
authority associated with the certificate. If verification of the certificate 
fails, then merchant computer system 130 concludes that the capture response is 
counterfeit and raises an error condition . 

Detailed Description Text (151) : 

In function block 1440, merchant computer system 130 validates payment gateway 
digital signature 1325. Merchant computer system 130 performs this validation by 
calculating a message digest over the contents of the combined basic capture 
response 1310 and signature public key certificate 1320. Merchant computer system 
130 then decrypts digital signature 1325 to obtain a copy of the equivalent message 
digest calculated by payment gateway computer system 140 in function block 1255. If 
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the two message digests are equal, then digital signature 1325 is validated. If 
validation fails, then merchant computer system 130 concludes that the 
authorization response is counterfeit and raises an error condition . 

Detailed Description Text (176) : 

An authorization without capture transaction is used to validate the card holder's 
account number for a sale that needs to be performed at a later stage. The 
transaction does not confirm a sale's completion to the host, and there is no host 
data capture in this event. The vPOS captures this transaction record and later 
forwards it to the host to confirm the sale in a forced post transaction request. 
An authorization without capture transaction can be initiated both by the consumer 
and the merchant. 

Detailed Description Text (180) : 

The return transaction is used to credit the return amount electronically to the 
consumer's account when purchased merchandise is returned. The vPOS captures the 
return transaction record when the merchandise is returned, and this transaction 
can be initiated only by the merchant. 

Detailed Description Text (182) : 

The pre-authorization transaction is identical to the authorization without capture 
transaction, but the consumers' "open-to-buy" amount is reduced by the pre- 
authorization amount. An example of this type of transaction is the "check-in" . 
transaction in a hotel environment. A check-in transaction sends a pre- 
authorization request to the host so that an amount required for the customers' 
stay in the hotel is reserved . The pre-authorization transaction is followed by a 
pre-authorization complete transaction. This transaction can be initiated both by 
the consumer and the merchant . 

Detailed Description Text (185) : 

The host administrative transactions do not require any payment instrument. The 
balance inquiry transaction is used for on-line inquiry into the balance of the 
merchant's account . The batch data or the configuration data is not affected by 
this transaction. 

Detailed Description Text (224): 

URL Functionality: Validates the cardholder's account number for a sale that is 
performed at a later stage. The transaction does not confirm the sale to the host, 
and there is no host data capture. The vPOS captures this transaction record and 
later forwards it to confirm the sale in the Forced Post transaction request. 

Detailed Description Text (317) : 

URL Functionality: Credits the return amount electronically to the consumer's 
account when previously purchased merchandise is returned. The vPOS terminal 
captures the transaction record for this transaction. 

Detailed Description Text (823) : 
Account Number (char[ ]) 

Detailed Description Text (954): 

For example, to fully qualify a particular merchant in a multi-merchant system, the 
ADT is queried to ascertain the particular Gateway (VFITest), then if Bank of 
America requires verification of network communication information, then the 
particular CDT is accessed with, for example, VISA. The particular merchant will 
service VISA transactions utilizing a particular acquirer. The particular piece of 
merchandise will also be detailed in a database. Finally, the merchant 
Configurations will also be stored in the database to facilitate E-mail and name 
lookup. 

Detailed Description Text (961) : 
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FIG. 20B is a prior art data structure 2002 representing a PCS transaction request. 
Data structure 2002 includes a TID field 2005, which identifies the physical 
terminal from which the transaction originates. In addition to the TID field, data 
structure 2002 also includes other data 2006 necessary to process a transaction, 
which includes such fields as a transaction type, a transaction amount, a currency 
type (such as U.S. dollars), credit card account number, and credit card expiration 
date . 

Detailed Description Text (962) : 

FIG. 20C illustrates a vPOS architecture in accordance with a preferred embodiment 
with account requests being processed by a single acquiring bank. A vPOS 2007 
processes a plurality of customers 2000 concurrently. For each such customer 2000, 
vPOS 2007 builds a data structure 2010, representing the transaction to be 
performed for that customer. Each data structure 2010 contains a unique "virtual 
terminal" ID. Then, vPOS 2007 selects a virtual terminal ID using a TID allocation 
database 2008. For each data structure 2010, vPOS 2007 initiates communication with 
acquiring bank 2004 using communication link 2003. 

Detailed Description Text (963) : 

FIG. 20D is a data structure 2010 representing a vPOS transaction request in 
accordance with a preferred embodiment. Data structure 2010 includes a TID field 
2012, which identifies a virtual terminal ID associated with a particular 
transaction. In addition to TID field 2012, data structure 2010 also includes other 
data 2006 necessary to process a transaction. Data 2006 includes such fields as a 
transaction type, a transaction amount, a currency type (such as U.S. dollars), 
credit card account number, and credit card expiration date. 

Detailed Description Text (967) : 

FIG. 20G depicts in detail the process of obtaining a TID from the database in 
accordance with a preferred embodiment. Execution begins in stage 2040. In stage 
2041, the routine constructs a database call to reserve a TID for processing, for 
example, by constructing an SQL statement to retrieve a TID row from the database. 
In stage 2042, the routine executes the database call that was constructed in stage 
2041. In stage 2043, the routine constructs a second database call to extract the 
TID from the row that was reserved in stage 2042. In stage 2044, the database call 
constructed in stage 2043 is executed to obtain the TID. In stage 2045, a return 
code is checked to verify whether the TID was successfully obtained. If the TID was 
successfully obtained, then control proceeds to stage 204 6, which returns to the 
calling program. However, if the TID was not obtained, then control proceeds to 
stage 2047. In stage 2047, the routine checks to see whether an excessive number of 
retries have already been attempted. If there have been an excessive number of 
retries, then control proceeds to stage 2048, which exits with an error indication. 
If there has not been an excessive number of retries, then control proceeds once 
again to stage 2043 to retry the extraction operation. 

Detailed Description Text (1141) : 

A preferred embodiment includes a single file or directory of files comprising a 
"wallet", which includes personal information and information about multiple 
payment methods. These payment methods (Visa cards, debit cards, smart cards, and 
micro-payments) also include information such as account numbers, certificates, key 
pairs, and expiration dates. The wallet can also include all the receipts and 
transaction records pertaining to every payment made using the wallet. A 
Cryptographic API component provides a standard interface for RSA and related 
cryptographic software or hardware. This support includes encryption, signature, 
and key generation. Choice of key exchange algorithm, symmetric encryption 
algorithm, and signature algorithm are configurable. A base class stipulates 
generic behavior, and derived classes handle various semantic options (e.g., 
software-based cryptography versus hardware-based cryptography.) 

Detailed Description Text (1171) : 
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